Managed Windows Services
Enterprise server
applications require high availability, reliability, and a management
view for on-going maintenance. Windows services provides these features.
Using Windows services to host a service requires hosting the ServiceHost instance from the WCF API in System.ServiceProcess. A Windows service is created in .NET by inheriting from the ServiceBase class, which lives in the System.ServiceProcess assembly. When a Windows service starts up, it calls the OnStart method and the ServiceHost instance is executed. Once the Windows service stops, the ServiceHost is closed, thereby tying the lifespan of the WCF service to that of the Windows service:
Example 5.
using System.ServiceModel;
using System.ServiceProcess;
public class AccountWindowsService : ServiceBase
{
ServiceHost serviceHost;
public override void OnStart( string[] args )
{
this.serviceHost = new ServiceHost( typeof( T ) );
this.serviceHost.AddEndpoint( ... );
this.serviceHost.Open();
}
public override void OnStop()
{
this.serviceHost.Close();
}
}
|
Hosting
in Windows services is useful when the lifetime of the service needs to
be controlled by the operating system. It is also beneficial when the
service has to run under the identity of a restricted account in the
background and can use any transport included in WCF.
IIS Process Boundary
In IIS, an application is the application domain and an application pool is the process boundary.
IIS includes health monitoring and recycling, allowing it to monitor
both the application domain and the application pool and to recycle
them if it determines idle behavior (indicating that IIS has choked and
is not able to service message requests).
IIS further
includes on-demand service activation via HTTP, which means that an IIS
application pool is only activated by the IIS infrastructure when it
receives an HTTP message. IIS also manages the lifecycle of the host.
Some benefits of hosting a service in IIS include:
scalability and several clustering features
process recycling, health monitoring, idle shutdown, message based activation
security
Hosting a service in IIS
5.0 and 6.0 limits the transport to HTTP and HTTPS. IIS 7.0 includes
Windows Activation Services and can host services with other transport
protocols.
A service that needs to be
hosted in IIS is typically represented by a .svc file, and with ASP.NET
it is separated from content using code-behind files. The .svc file
uses the ServiceHost directive to identify and link to the code-behind file containing the service class, as shown here:
Example 6.
<%
@ServiceHost language="cs"
Class="GreetingService"
CodeBehind="~/App_Code/GreetingService.cs"
%>
|
The .svc file can be hosted
in an IIS virtual directory, but in order to make a service public, it
must be configured in the Web.Config file:
Example 7.
<system.serviceModel>
<services>
<service type="GreetingService">
<endpoint
address=""
binding="basicHttpBinding"
contract="GreetingService" />
</service>
</services>
</system.serviceModel>
|
Typically,
the address in the Web.Config file is set to an empty string, as this
address is relative to the address of the .svc file in IIS. To host
this .svc file in IIS, the .svc extension must be mapped to the ASP.NET
process (aspnet_isapi.dll), which can be set in the IIS Application
Configuration Window.
Once a service is hosted in IIS, it can be accessed using a Web browser. In this case, the URL to access the service is:
http://localhost/GreetingService.svc
Windows Activation Services (WAS)
Windows Activation
Service (WAS) is a system service introduced with Windows Vista. It is
the activation part of IIS 7.0 and can also be installed and configured
separately.
IIS 5.0 and IIS 6.0 are
appropriate hosting platforms as long as the only transport used is
HTTP. WAS is built upon the IIS 6.0 activation model by generalizing
the IIS 6.0 process model and extending it to other transports, such as
TCP and MSMQ (Figure 1).
WAS architecture introduces listener adapters—infrastructure
components that bridge particular network protocols to the WAS
interface. The listener adapter communicates messages to WAS and
requests that it activate worker processes. WAS includes listener
adapters for all activation scenarios in WCF, including http, net.tcp,
net.pipe, and net.msmq.
Since WAS is built on IIS
6, it provides all the features included in IIS, such as process
recycling, application pooling and isolation, identity management,
health activation monitoring, message based activation, and so on.
Similar to hosting a service in IIS, hosting a service in WAS requires
a .svc file which is a pointer to a code-behind file containing the
service class.
Hosting REST Services
WCF provides the WebServiceHost for REST-based services, which is a REST-aware equivalent of the ServiceHost class. WebServiceHost ensures that the transport is HTTP and wires up the service endpoints to the REST dispatcher. It also works with WebServiceHostFactory and the WCF configuration-less model.
Each .svc file contains two WCF-specific attributes:
When the Factory attribute is absent, the supporting WCF infrastructure will set the value to System.ServiceModel.Activation.ServiceHostFactory.
This particular factory depends on the Web.Config file to figure out
how to host the service, expose endpoints, and attach any behaviors.
Because a REST service has
a well-defined set of behaviors, instead of explicitly stating what the
binding and behavior set looks like, you can set the Factory attribute to System.ServiceModel.Activation.WebServiceHostFactory and skip any configuration altogether. In fact, the following CatalogService (found in CatalogService.svc and CatalogService.svc.cs) does just that:
Example 8.
<%@
ServiceHost Language="C#" Debug="true"
Service="StandardMold.Catalog.CatalogService"
Factory="System.ServiceModel.
Activation.WebServiceHostFactory"
%>
|
